같은 카드가 여러 번 나올 수 있나요?

확인해보니 말씀해주신 것처럼 같은 카드가 여러 번 출력되는 문제가 있었습니다.
플레이어별로 핸드를 조회해야 하는 부분에서 잘못된 참조가 이루어지고 있는 것 같습니다.

해당 문제 해결하고 다시 커밋 올리겠습니다. 감사합니다!

Controller 도입에 대한 고민
주디가 생각하시는
Controller가 필요한 상황은 어떤 경우인지
이번 미션에서 Controller를 도입한 제 선택이 오버 엔지니어링으로 느껴지셨는지
혹은 Controller 없이 도메인 객체 중심으로 흐름을 구성하는 것이 더 나은 접근이었는지

정답은 아니지만 제 생각을 말씀드리면요,

Controller라는 개념은 결국 MVC 패턴에서 나온 것 같아요.
패턴이라는 것은 많은 개발자들이 다양한 요구사항을 구현하면서 "이런 상황에서는 이런 방식으로 설계하는 것이 더 낫겠다"는 경험이 쌓여 만들어진 것이라고 생각해요~ 그래서 반드시 적용해야 하는 것도 아니고, 항상 정답이 되는 것도 아니라고 생각합니다!

MVC 패턴은 특히 View가 존재하는 상황에서 역할을 분리하기 위해 도입하기 좋은 패턴이라고 생각합니다.
사용자 입력과 출력이 있고, 그 사이에서 흐름을 조정해야 할 때 Controller가 자연스럽게 등장하게 되는 것 같아요.
그래서 이번 미션에서 Controller를 도입한 것이 오버엔지니어링이라고 느껴지지는 않습니다.
게임 진행 흐름을 관리하고, 입력과 출력을 연결하는 객체가 하나 있는 구조 자체는 충분히 자연스러운 설계라고 생각합니다.

다만 한편으로 들었던 생각은 PR을 보면서 패턴이라는 것이 당연히 사용해야 하는 구조처럼 받아들이시는 분들이 있어보여요..!
패턴은 알고, 이해하고, 왜 필요한지 납득한 상태에서 사용하는 것이 좋다고 생각하는데, 때로는 그런 고민 없이 "원래 이렇게 하니까", "다 이렇게 하니까"라는 이유로 적용되는 경우도 있는 것 같아요.

그리고 말씀해주신 것처럼 도메인 객체들이 응집성 있게 협력하도록 만들고 외부에서는 하나의 진입 메서드만 호출하도록 구성하는 방식도 충분히 좋은 설계가 될 수 있다고 생각합니다!! 상황과 구조에 따라 두 방식 모두 선택지가 될 수 있을 것 같아요.

다만 말씀주신 Controller의 역할이라면 GameManager라는 도메인을 Controller가 상태로 가지고 있는게 맞는지에 대한 고민은 해보면 좋을 것 같아요!

Controller 도입에 대해 정리해주신 관점이 많이 도움이 되었습니다.

저도 처음에는 입력과 출력 사이의 흐름을 조정하는 역할이 필요하다고 생각해서
Controller를 두는 구조를 선택했습니다.
말씀해주신 것처럼 View가 존재하고 사용자 입력과 출력이 있는 상황에서는
흐름을 조정하는 객체가 있는 것이 자연스럽다고 생각했습니다.

어느쪽이 맞는지 많은 고민이 되었던 만큼 둘 다 근거가 있는 선택지가 될 수 있을 것 같다는 의견에 마음이 놓입니다.

다만 리뷰를 읽으면서 말씀해주신 것처럼
Controller가 GameManager를 상태로 가지고 있는 구조가 적절한지에 대해서는
조금 더 고민해볼 필요가 있겠다는 생각이 들어서 제 코드를 자세히 살펴보았습니다.

현재 제 GameManager는 도메인이라기 보다는,
Players, Dealer, Deck을 조율하면서 게임 진행 흐름을 관리하는 객체에 가까운 것 같습니다.
그래서 컨트롤러가 매니저를 상태로서 가지고 있는 것도 문제는 아니지 않을까? 생각합니다.

다만 플레이어 정보를 컨트롤러가 직접적으로 참조하고 있다는 점이 계속 신경쓰이는 것 같습니다.
최선의 구조는 아니지만 현재의 제가 떠올릴 수 있는 구조에서는 가장 합리적인 구조라고 판단되어
현재의 코드를 유지할 것 같지만 컨트롤러의 책임을 덜 수 있는 구조가 무엇이 있을지 계속 고민해보아야 할 것 같습니다.

좋은 의견 감사합니다!

설계 결정을 내릴 때의 기준에 대한 고민
도메인 설계를 할 때
여러 설계 선택지 중 하나를 결정할 때 어떤 기준으로 판단하시는지
경험이 부족한 초보 개발자가 설계 결정을 할 때 중요하게 잡아야 할 기준이 무엇인지
에 대해 조언을 듣고 싶습니다.

일단 확신이 서지 않는다라고 말씀해 주셨는데 너무 조급해하실 필요는 없을 것 같아요!
지금 말씀해주신 고민 자체가 바로 그 기준을 만들어가는 과정이라고 생각해요 :)

설계를 하다 보면 사실 정답이 있는 경우는 많지 않은 것 같아요~ 같은 문제라도 개발자마다 다른 구조를 선택하기도 하고, 상황에 따라 더 적절한 설계가 달라지기도 하니까요!
그래서 저는 설계 결정을 할 때 항상 고려하는 부분은 아래 세 가지인데요.

1. 코드가 요구사항대로 동작하는가
2. 다른 사람이 읽었을 때 이해하기 쉬운가
3. 이후에 변경이 생겼을 때 수정하기 쉬운 구조인가

여러 설계 선택지가 있을 때는 결국 이 세 가지 기준에서 어느 쪽이 더 나은지 생각해보고 결정하는 편입니다!

또 초보 개발자가 설계 결정을 할 때 가장 중요하게 가져가면 좋은 기준은 단일 책임 원칙(SRP)이라고 생각합니다.
객체가 너무 많은 일을 하고 있지는 않은지, 하나의 객체가 하나의 책임에 집중하고 있는지를 계속 의심해보는 것만으로도 설계가 꽤 많이 정리되는 경험을 하게 되는 것 같아요~

말씀해주신 기준들이 많이 도움이 되었습니다.

혼자 설계 할 때 명확한 정답이 없는 문제다 보니 답답함을 느낄 때가 많았는데,
정리해주신 것처럼

1. 요구사항대로 잘 동작하는지
2. 다른 사람이 읽고 이해하기 쉬운 구조인지
3. 이후 변경이 생겼을 때 수정하기 쉬운지

이 세 가지 기준으로 비교해보는 방식이 판단할 때 좋은 기준이 될 것 같습니다.

이번 미션에서는 기능 구현에 집중하다 보니 설계 결정을 내릴 때 이런 기준을 충분히 적용하지 못했던 것 같아 아쉬움이 남습니다.

앞으로는 설계 선택지가 여러 개 있을 때 말씀해주신 기준들을 가지고
조금 더 의식적으로 비교해보는 연습을 해보겠습니다. 좋은 조언 감사합니다!

테스트와 설계의 관계에 대한 고민
테스트하기 어려운 코드가 나타났을 때 어떤 설계 문제를 먼저 의심하시는지
테스트를 기준으로 설계하는 경험은 어떻게 연습해야 할지

먼저 테스트하기 어려운 코드가 나타났을 때 어떤 설계 문제를 의심하시는지에 대해 제 생각을 말씀드리면요,
테스트가 어려운 코드가 아래와 같은 경우가 있다고 생각하는데요~

1. 하나의 객체가 너무 많은 책임을 가지고 있는 경우
   테스트해야 할 경우의 수가 너무 많아지거나, 테스트 코드가 지나치게 복잡해지는 경우가 있습니다.
   이런 경우에는 책임을 나누어 객체를 분리할 수 없는지 먼저 고민해보는 것 같습니다~!

2. 테스트에서 컨트롤하기 어려운 요소에 의존하고 있는 경우
   예를 들어 랜덤 값, 시간, 입출력 같은 부분이 직접 로직 안에 들어가 있으면 테스트하기가 어려워지지용
   이런 경우에는 해당 부분을 최대한 분리하는 방향을 고민하게 되는 것 같습니다.

3. 다른 객체들과 너무 복잡하게 얽혀 있는 경우
   여러 객체가 강하게 결합되어 있으면 테스트를 작성하기가 점점 어려워진다고 생각해요.
   이럴 때는 구조를 조금 단순하게 만들 수 없을지 고민하기위해 "이 요구사항을 해결하기 위해 어떤 메시지가 필요한지"를 먼저 생각한 뒤 각 메시지를 담당할 객체를 나누는 방향으로 설계를 다시 바라보곤해요!

그리고 테스트를 기준으로 설계하는 경험을 어떻게 연습하면 좋을지에 대해서는, 지금 느끼신 어려움의 원인 중 하나가 입출력 부분을 테스트하기 어렵기 때문일 수도 있겠다는 생각이 들었습니다.

나중에 교육 과정에서 배우시겠지만 인수 테스트라는 개념이 있는데요, 인수 테스트는 시스템의 전체 흐름이 요구사항대로 동작하는지 확인하는 테스트입니다.
지금 미션에서는 입출력을 직접 테스트하기 어려운 구조라서 전체 흐름을 테스트하기가 쉽지 않지만, 만약 그런 테스트가 가능해지면 전체 흐름을 테스트로 먼저 작성하고 -> 테스트가 실패하는 상태(Red)를 만들고 -> 코드를 수정해서 통과(Green)시키고 -> 구조를 정리하는 리팩토링

이 과정을 통해 테스트가 설계를 이끄는 경험을 조금 더 자연스럽게 할 수 있을 것 같아요!

그래서 지금 상황에서는 전체 흐름을 완전히 테스트하기는 어렵더라도, 이 게임이 진행되기 위해서는 어떤 메시지들이 오가야 할까? 정도를 먼저 생각해보고 그 메시지를 기준으로 테스트를 작성해보는 연습을 해보셔도 좋을 것 같습니다!

이렇게 접근하면 객체를 먼저 만들고 테스트를 맞추는 방식보다는, 테스트를 통해 설계를 조금씩 만들어가는 경험을 더 해보실 수 있을 것 같아요~

상세한 답변 감사합니다!

지금까지는 테스트가 어려우면 작성 방법 자체를 먼저 고민했던 것 같은데,
말씀해주신 내용을 보고 나니 그 전에 설계적으로 무엇이 테스트를 어렵게 만드는지부터
살펴보는 것이 먼저라는 점을 배운 것 같습니다.

특히 책임이 과한 객체, 분리되지 않은 입출력/상태, 강한 결합을 먼저 의심해보라는 부분이 인상적이었습니다.
앞으로는 전체 흐름에서 필요한 메시지를 먼저 생각하고,
그 메시지를 기준으로 테스트를 작성하면서 설계를 다듬는 연습을 해보겠습니다.

감사합니다 😀

미션 요구사항과 도메인 설계 기준이 충돌할 때의 판단 기준

먼저 미션의 요구사항은 가이드에 가깝지 반드시 절대적인 법칙이라고 생각하지는 않아요.
다만 요구사항을 지키지 않는 선택을 한다면 왜 그렇게 판단했는지에 대한 분명한 이유는 있어야 한다고 생각합니다!

현업에서는 사실 이런 형태의 요구사항이 거의 없는 경우도 많습니다..! 시스템의 규모가 크고 복잡하기 때문에 "필드는 몇 개까지", "getter는 사용하지 않는다"처럼 구체적인 제약이 주어지기보다는 각 팀의 컨벤션이나 설계 기준을 기반으로 판단하게 되는 경우가 많습니다.

그래서 저는 미션에서 제시된 규칙들은 실제 도메인 설계를 강제하기 위한 규칙이라기보다는, 객체지향 설계를 연습하기 위한 교육용 제약에 가깝다고 생각합니다.
예를 들어 "인스턴스 변수를 3개 이하로 제한한다", "컬렉션을 포장한다" 같은 규칙은 특정 상황에서 반드시 지켜야 하는 절대적인 설계 원칙이라기보다는, 객체의 책임을 나누고 설계를 고민해보게 만들기 위한 장치라고 생각하거든요!

다만 한 가지 기준으로 생각해보면, 이 정도 규모의 미션에서 규칙을 지키지 못하는 부분이 너무 많이 발생한다면 설계를 의심해봐야할 것 같아요~!
이 규칙들은 "적어도 이 정도 규모에서는 이런 방식으로 설계해볼 수 있다"는 방향을 제시해주는 것으로 보여서요!

최대한 규칙을 지키기 위해 의식하면서 개발에 임하면서도, 타협이 필요하다면 그 이유에 대해 깊게 생각해보는 것이 도움이 될 것 같습니다.

특히 '미션에서 규칙을 지키지 못한 부분이 많이 발생한다면 설계를 의심해보아야 한다'는 말이 와닿았습니다. 블랙잭 미션의 규모에서도 이러한 규칙들을 지키지 못한다면 설계 방식을 검토할 신호이기도 한 것 같네요..!
정성적인 리뷰 감사합니다 😀

사용되지 않는데 필요할까요?

이전 사이클의 기능이었는데 이제는 필요가 없어져서 제거하는게 맞는 것 같습니다..!

dto에 패키지 위치가 domain에 있는 이유가 궁금해요 :)

DTO를 domain 패키지에 둔 것에 특별한 의도가 있었던 것은 아니고,
DTO의 역할에 대해 명확하게 이해하지 못한 상태에서 위치를 결정했던 것 같습니다.

리뷰를 보고 DTO의 역할에 대해 다시 생각해보니,
DTO는 계층 간 데이터 전달을 위한 객체에 가깝기 때문에
domain 보다는 별도의 dto 패키지나 상위 계층에 두는 것이 더 적절한 것 같습니다.

말씀해주신 내용을 반영해 패키지 구조를 다시 정리해보겠습니다. 감사합니다.

if문을 줄일 방법이 더 없을까요! enum을 잘 활용해보면 어때요?

리뷰를 받고 if문을 줄이는 방법으로 Predicate enum 방식을 검토해봤습니다.

다만 해당 방식은 조건과 판정 흐름이 분리되어 블랙잭 룰을 한눈에 파악하기 어려워지고, 읽기에 단순한 조건 5개를 줄이려다 복잡도가 올라가는게 아닐까 하는 생각이 들었습니다. 현재의 조건문 순서는 블랙잭2의 규칙을 가장 직관적으로 보여주고 있다고 생각했거든요..

그래서 if문은 유지하되, 판정 책임을 Result.from(player, dealer) 형태로 옮겨 Result가 스스로 자신의 값을 결정하도록 리팩토링하는 방향은 어떻게 생각하시나요?

이번 사이클에 미션 중 기록이 있었던거 같은데 README나 PR에는 따로 안적어주시나요?!

기능 추가로 인해 수정한 위치 개수
사이클1 때보다 수정 범위가 줄었는가/늘었는가
규칙 적용으로 변경한 코드 1곳
테스트가 설계를 도운 순간 1회

기록을 해두었는데 PR에서 질문 거리를 고민하다가 적는 것을 놓쳤습니다 🥲
README에 업데이트하여 커밋해두겠습니다..!

요기 어차피 2만 들어가는데 굳이 상태로 가져야하는지 모르겠어요!

처음 설계를 할 때에는 확장 가능성을 고려해서 초기 핸드의 크기가 바뀌었을 때 대처할 수 있도록 상태로 다루고자 하여 도입했었습니다. 리뷰를 받고 코드를 돌아보니 DTO 변수로 만든다는 것은 생성 책임도 생기고, 코드를 보는 입장에서 의문이 생길 만한 코드 인 것 같습니다.

남겨주신 리뷰를 읽고 확장성에 대한 판단을 어떻게 해야할지 찾아보다가 YAGNI에 대한 내용을 접하게 되었는데, 항상 코드를 작성하면서 '이렇게 확장된다면 어떡하지?'라는 생각으로 당장 쓸 필요가 없는 코드 구조를 도입한 적이 많은 것 같습니다.

우선 해당 필드를 제거하고, 앞으로도 '확장하기 쉬운 코드'와 '확장을 대비해서 필요없는 코드를 미리 써두는 것'을 잘 구분해서 개발을 해야할 것 같습니다